Die Bitmaph�he h�ngt hier wie beim Scroller_XLimited Algorithmus von der Levelbreite ab. In den allermeisten F�llen ergibt sich aber eine sehr vertretbare Extrah�he (zus�tzlich zu den 288 Zeilen (256 + BLOCKH�HE * 2)) , soda� das kein gro�er Nachteil ist. Bei einer Levelbreite von 16000 Pixeln (50 Screens) kommt man z. B. mit weniger als 15 Extrazeilen aus. Die Vertikal-Nachf�llreihe besteht jetzt aus 22 Bl�cken (22 * 16 = 352), weil die Bitmap wegen dem horizontalen Scrolling breiter sein mu�. Die Horizontal-Nachf�llspalte m��te analog jetzt aus 18 Bl�cken (18 * 16 = 288) bestehen, weil die Bitmap wegen vertikalen Scrolling jetzt h�her sein mu�. Da sich dann aber beide Nachf�llbereiche �berschneiden w�rden, verwenden wir f�r die Horizontal-Nachf�llspalte nur 17 Bl�cke und verschieben sie einen Block nach unten. Das kann man sich so vorstellen:

Die einzelnen Scroll-Routinen sind jetzt um einiges komplizierter. Das ist deshalb so, weil sich die Nachf�llspalte und die Nachf�llreihe beim Scrollen verschieben und beide voneinander abh�ngen. Die Verschiebung geschieht nur alle BLOCKBREITE bzw. BLOCKH�HE Pixel, und wenn das geschieht, mu� der jeweils andere Nachf�llbereich mit verschoben werden. Das sehen wir uns jetzt bei allen Scrollfunktionen genauer an.

Nach-Rechts-Scrollen: Ausgangsposition (A) ist (0,3). Zielposition (B) ist (16,3). Da wir uns vertikal nicht an einer durch 16 (BLOCKH�HE) teilbaren Position befinden, sind in der Vertikal-Nachf�llreihe ein paar 'Nachf�llbl�cke' ('Unten-Bl�cke') vorhanden:

Die gr�nen Bl�cke zeigen die Position der Horizontal-Nachf�llspalte. In dieser Spalte befinden sich keine Nachf�llbl�cke, da das Verschieben der Nachf�llspalte nur an durch 16 (BLOCKBREITE) teilbaren Levelpositionen passiert. Die gr�nen Bl�cke sind also zu den normalen (grauen) zu z�hlen.

Nach den normalen Scroll-Routinen befinden wir uns in Situation (B). Die Vertikal-Nachf�llreihe mu� offensichtlich korrigiert werden, damit sie wieder richtig, d. h. wie in (C) ist. Der Block ganz links oben (1. Pfeil) ist ein Nachf�llblock (rot), mu� aber zu einem normalen Block (grau) werden. Dadurch befindet sich in der Vertikal-Nachf�llreihe aber ein Nachf�llblock (rot) zu wenig. Wir blitten also auch den jetzt(!) ganz rechten Nachf�llblock (2. Pfeil). Das machen wir nat�rlich nur, wenn die Vertikal-Nachf�llreihe Nachf�llbl�cke (= rote Bl�cke) enth�lt, d. h. LevelPositionY nicht durch 16 (BLOCKH�HE) teilbar ist, d. h. der aktuelle vertikale Schritt ungleich 0 ist.

Nach-Links-Scrollen: Ausgangsposition (A) ist (16,3). Zielposition (B) ist (0,3). Da wir uns vertikal nicht an einer durch 16 (BLOCKH�HE) teilbaren Position befinden, sind in der Vertikal-Nachf�llreihe ein paar 'Nachf�llbl�cke' ('Unten-Bl�cke') vorhanden:

Auch hier ist die Vertikal-Nachf�llreihe nach den normalen Scrollroutinen nicht ganz in Ordnung. Um aus (B) (C) zu machen, gehen wir wie folgt vor. Der Block ganz links oben (1. Pfeil) mu� neu geblittet werden. Da sich in der Vertikal-Nachf�llreihe einige Nachf�llbl�cke befinden, mu� aus dem normalen (grauen) Block ein Nachf�llblock (rot) werden. W�ren da keine Nachf�llbl�cke in der Vertikal-Nachf�llreihe, m��ten wir den Block trotzdem blitten, aber als normalen (grauen) Block, n�mlich deshalb, weil die normalen horizontalen Scrollfunktionen den Bereich der Vertikal-Nachf�llreihe ignorieren. Deshalb ist der Block ganz links oben der Block (22,0) des Levels. Das war richtig f�r die LevelPositionX 16, aber nicht f�r LevelPositionX 0. Dort mu� der Block entweder der Block (0,0) des Levels sein, d. h. ein normaler Block, oder der Block (0,18), d. h. ein Nachf�llblock der Vertikal-Nachf�llreihe. Wenn die Nachf�llreihe Nachf�llbl�cke enth�lt, dann haben wir jetzt einen Nachf�llblock (rot) geblittet, und dadurch befinden sich dort jetzt zu viele Nachf�llbl�cke. Deshalb m�ssen wir dann, und nur dann(!), den vormals(!) ganz rechten Nachf�llblock (2. Pfeil) mit dem entsprechenden normalen (grauen) Levelblock �berblitten.

Nach-Unten-Scrollen: Ausgangsposition (A) ist (3,0). Zielposition (B) ist (3,16). Da wir uns horizontal nicht an einer durch 16 (BLOCKBREITE) teilbaren Position befinden, sind in der Horizontal-Nachf�llspalte ein paar 'Nachf�llbl�cke' ('Rechts-Bl�cke') vorhanden:

Die roten Bl�cke zeigen die Position der Vertikal-Nachf�llreihe. In dieser Reihe befinden sich keine Nachf�llbl�cke, da das Verschieben der Nachf�llreihe nur an durch 16 (BLOCKH�HE) teilbaren Levelpositionen passiert. Die roten Bl�cke sind also zu den normalen (grauen) zu z�hlen.

Nach den normalen Scroll-Routinen haben wir das Problem, da� sich die Horizontal-Nachf�llspalte nicht dort befindet, wo sie es eigentlich sollte, es sei denn, es befinden sich keine Nachf�llbl�cke in der Horizontal-Nachf�llspalte - dann brauchen wir hier im Gegensatz zur Korriegierung der Vertikal-Nachf�llreihe beim Nach-Links/Rechts-Scrollen, wo mindestens ein Block immer geblittet werden mu�, gar nichts machen. Wenn wir nicht soviel Gl�ck haben, m�ssen wir zwei Bl�cke blitten. Zum einen ist das der Block ganz links (1. Pfeil) in der neuen Vertikal-Nachf�llreihe, (2. Block von oben ganz links), der zu einem Normal-Block (grau bzw. rot) werden mu�, weil Nachf�llbl�cke der Horizontal-Nachf�llspalte nichts in der Vertikal-Nachf�llreihe zu suchen haben. Zum anderen ist das der jetzt(!) ganz-unten-liegende Nachf�llblock (2. Pfeil). Dieser Block ist zur Zeit ein normaler (grauer) Block, mu� aber zu einem Nachf�llblock (gr�n) werden. Hier ist zu beachten, da� das Aussehen der Horizontal-Nachf�llspalte davon abh�ngt, in welche Richtung wir zuletzt horizontal gescrollt sind, egal wie lange das her ist. Wenn wir zuletzt nach rechts gescrollt sind, dann sieht sie wie in (A) aus, wenn wir zuletzt nach links gescrollt sind, dann sieht sie wie in (B) aus:

Wir m�ssen einen Nachf�llblock ('Rechts-Block') blitten, d. h. wir haben keinerlei Probleme, wenn die letzte Horizontal-Scroll-Richtung rechts (A) war. War die letzte Horizontal-Scroll-Richtung aber links (B), dann wurde durch sie die letzte Planeline jenes Nachf�llblockes zerst�rt, der �ber dem liegt, den wir �berblitten, d. h. den vorher(!) ganz-unten-liegenden Nachf�llblock. Beim Nach-Links-Scrollen wurde zum Gl�ck ein Backup von dieser Planeline gemacht, soda� wir sie jetzt restaurieren. Danach k�nnen wir unseren Nachf�llblock - ein 'Rechts-Block' blitten, nat�rlich nachdem wir von jener Planeline ein Backup gemacht haben, die der Blit vom darunterliegenden normalen Block zerst�ren wird. Wir m�ssen die Letzte-Scroll-Richtung-Variable schlie�lich noch auf RECHTS setzen, um den 'Zustand' (A oder B) der Nachf�llspalte auch sp�ter und an anderen Stellen richtig bestimmen zu k�nnen.

Nach-Oben-Scrollen: Ausgangsposition (A) ist (3,16). Zielposition (B) ist (3,0). Da wir uns horizontal nicht an einer durch 16 (BLOCKBREITE) teilbaren Position befinden, sind in der Horizontal-Nachf�llspalte ein paar 'Nachf�llbl�cke' ('Rechts-Bl�cke') vorhanden:

Auch hier ist die Horizontal-Nachf�llspalte nach den normalen Scroll-Routinen nicht dort, wo sie sein sollte, sofern sie Nachf�llbl�cke enth�lt. Tut sie das nicht, dann ist alles in Ordnung und wir brauchen nichts zu korrigieren. Meistens werden wir aber nicht so viel Gl�ck haben. Dann m�ssen wir zwei Bl�cke blitten. Zum ersten ist das der jetzt(!) ganz oben-liegende bzw. erste Nachf�llblock (1. Pfeil) der Horizontal-Nachf�llreihe. Dieser Block war ein normaler Block, mu� aber zu einem Nachf�llblock (gr�n) werden. Zum zweiten ist das der vormals(!) ganz-unten liegende Nachf�llblock (2. Pfeil). Dieser Block mu� zu einem Normal-Block werden. Hier m�ssen wir wieder die verschiedenen 'Zust�nde' der Nachf�llspalte beachten. War die letzte Horizontal-Scroll-Richtung links, dann ist alles in Ordnung. War sie aber rechts, dann wurde durch sie die erste Planeline jenes normalen Blocks �berblittet, der unter dem liegt, den wir �berblitten. Beim Nach-Rechts-Scrollen wurde zum Gl�ck ein Backup von dieser Planeline gemacht, soda� wir sie jetzt restaurieren. Danach k�nnen wir unseren Block - ein 'Normal/Links-Block' blitten, nat�rlich nachdem wir von jener Planeline ein Backup gemacht haben, die der Blit vom dar�berliegenden Nachf�llblock zerst�ren wird. Wir m�ssen die Letzte-Scroll-Richtung-Variable schlie�lich noch auf LINKS setzten, um den 'Zustand' der Nachf�llspalte auch sp�ter und an anderen Stellen richtig bestimmen zu k�nnen.

Was gibt's sonst noch zu sagen? Beim Modulo-Trick gibt's ein paar kleine �nderungen. Wegen dem horizontalen Scrolling werden vom Videochip mehr als 320 Pixel pro Zeile gelesen. Je nach FETCH Modus sind das 16 (1x), 32 (2x) oder 64 (4x) Pixel. Das mu� in der Berechnung des Spezial-Modulos ber�cksichtigt werden. Es ist aber nicht notwendig, die Berechnung in die UpdateCopperlist() Funktion zu verlagern, obwohl die Adresse, auf die wir die Planepointer in der VIDEOSPLIT Rasterzeile umbiegen m�ssen, im Gegensatz zum Scroller_YUnlimited2 Algorithmus nicht mehr konstant ist. Wir k�nnen uns das sparen, weil der Offset zwischen alter Adresse und neuer Adresse konstant bleibt. Damit bleibt auch der Spezial-Modulo stets konstant. In die UpdateCopperlist() Funktion verlagern m�ssen wir aber die Routinen, die die Hiwords setzen, weil die VIDEOSPLIT-Planeadressen wie bereits gesagt, nicht konstant sind. Sie werden zwar nur vom Horizontalscrolling beeinflu�t, aber leider ist unsere Bitmap nicht entsprechend aligned, um garantieren zu k�nnen, da� die Hiwords konstant bleiben.

Noch einige Bemerkungen zum Quelltext des Demoprogrammes. Horizontal sind die ersten BLOCKBREITE (16) Pixel und vertikal die ersten BLOCKH�HE (16) Pixel des Levels nicht sichtbar. Ist die Levelposition (mapposx,mapposy) dann sieht der User den folgenden Levelbereich:

(mapposx + BLOCKWIDTH,mapposy + BLOCKHEIGHT) -
(mapposx + BLOCKWIDTH + SCREENWIDTH - 1,mapposy + BLOCKHEIGHT + SCREENHEIGHT - 1)

Will man in die Bitmap etwas hineinblitten, z. B. Blitter Objekte (BOBs), dann mu� man das im aktuell sichtbaren Bitmapbereich machen. Dieser Bereich ist:

(videoposx + BLOCKWIDTH,(videoposy + BLOCKHEIGHT) % BITMAPHEIGHT) -
(videoposx + BLOCKWIDTH + SCREENWIDTH - 1,(videoposy + BLOCKHEIGHT + SCREENHEIGHT - 1) % BITMAPHEIGHT)

Die Start-Koordinaten d�rfen auf ein Vielfaches von BLOCKWIDTH bzw. BLOCKHEIGHT ab-, die End-Koordinaten aufgerundet werden. Damit ergibt sich ein blitbarer Bereich von (SCREENWIDTH + BLOCKWIDTH) x (SCREENHEIGHT + BLOCKHEIGHT) Pixeln. Auch bei diesem Algorithmus kann es vorkommen, da� die Ende-Y-Koordinate �ber der Start-Y-Koordinate liegt, d. h. kleiner ist. Das liegt am Videosplitting und bedeutet nichts anderes, als da� der Bereich von der Startkoordinate bis zum Ende der Bitmap geht, dann an den Anfang der Bitmap "wrappt" und dort noch bis zur Endkoordinate reicht. F�r das Blitten in den Blitbereich folgt daraus, da� man sich die Blith�he und die errechnete Blit-Ziel-Y-Position (blitbereich_strty + ziely) genau anschauen mu�:

Wenn BLITZIELY + BLITH�HE <= BITMAPH�HE dann:

Ganz normal an Y-Position BLITZIELY blitten

andernfalls, wenn BLITZIELY >= BITMAPH�HE dann:

Ganz normal an Y-Position (BLITZIELY - BITMAPH�HE) blitten

andernfalls:

Die ersten (BITMAPH�HE - BLITZIELY) Pixelzeilen an Y-Position BLITZIELY blitten
Die letzten BLITH�HE - (BITMAPH�HE - BLITZIELY) Pixelzeilen an Y-Positionen 0 blitten.